[t:/]$ 지식_

MR 느낌의 일을 파케이parquet로 처리하는 느낌적인 느낌

2020/01/30

시작합니다. 제한시간 5분!

검증되지 않은 추정의 추론의 상상의 공상으로 쓴 글.

먼저 파케이 형식을 뜯어보자. 컬럼 기반 형식이다. 예를 들어 이름-성별-종교의 레코드가 있다 치자. 파케이에서는 레코드가 3개일 때 이렇게 처리한다.

이명박
박근혜
황교안
남자
여자
남자
기독교
우주
기독교

이게 컬럼 기반 파일이다.

파케이는 장점이 여럿 있는데 일단 파일이 빡빡하다. 각 필드를 길이와 오프셋으로 처리하는 것 같다.(스펙을 읽다 말아서 확신은 없지만 대충 미녀 인강 강사가 설명하는 짤방 삽입) 즉, 파일이 빽빽하게 들어서 있다. 빅 데이터에서는 데이터가 빽빽하게, 즉 크기를 작게 가져가는 것이 유리하다. 속도를 쥐어짜서 십시일반하면 전체 성능에서 큰 차이가 나니까.

가장 큰 장점은 컬럼 기반 처리, 즉슨 대부분의 데이터 프레임 형태에서 하는 SQL 느낌의 업무에서 성능이 더욱 좋다. 예컨데 성별로 group by 카운트를 한다치면 바로 성별 위치로 점프해서 스캔해가며 아주 훌륭하게 처리할 수 있다. 중간에 낑긴 컬럼으로 조인을 한다면 그 컬럼으로 점프해서 쏘팅 뜨고 뭐 그러면 훨씬 빠를 것 같다.

문제는 MR 느낌의 업무를 처리할 때에는 손해를 보는 느낌적 느낌이 든다는 거시다. 남자만 골라서 이름과 종교를 추출하라는 업무라치자. 전 필드를 다 봐야한다. 컬럼 기반의 장점이 희석된다. 나는 로우레벨 기술자니까 아래쪽을 좀 보면 더욱 문제다. 하드디스크라면 헤드가 뺑이를 쳐야 한다. 위아래위위아래. 드륵드륵 소리도 다르게 날껄? 게다가 오프셋과 길이 계산 한다고 뺑이쳐야 한다. SSD라도 문제는 있다. 캐시의 잇점을 하나도 못 누린다. MR로 레코드 기반으로 처리한다면 이름 읽을 때 이미 캐시에 성별과 종교도 들어온다. 파일 read 할 때 이미 페이지 캐시 단위로, 버퍼링 단위로 펑펑 땡겨온다. 성능이 비할 바가 아니다. 결국 MR 느낌적 느낌의 업무에서는 그냥 레코드 기반 파일로 처리하는 것이 낫다는 뜻이다. 어차피 인덱스도 없는데 무식하게 뺑이 칠 때는 캐시라도 딱딱 맞아야징.

아쉽게도 날 텍스트 파일에서는 파일이 빽빽하지가 않다. 빅데이터에서는 빈 필드가 대부분이다. delim 처리한다고 귀찮은 일도 많다. 물론 내가 하면 100배 빠르게 할 수 있지만 (대충 뭔 개소리야 한심해 하는 짤) 대부분은 나이브하게 짜는 것 같다. 프로토버프 비슷하게 빡빡하고 스키마스럽고 바이너리 처리하면 좋을텐데 내가 하는 멍텅구리 MR 에서는 이게 쉽지가 않다. 쓰리프트인가 뭔가 있는 것 같은데 내가 잘 모른다.

한 편, 스팍 모니터링 화면을 보고 있노라면 한심 답답할 때가 많은데 특성상 이종 언어가 들어가는 관계로 자료형 마샬링/언마샬링 한다고 뺑이를 치는 것 같다. 파이썬 UDF가 그랬던 것 같다. 모두가 위아더월드 같은 바이너리로 빡빡하게 넣으면 좋건만 언어마다 서로 다른 자료구조 맞춘다고 뺑이치는 것 같다.

더 아는 것도 없고 상상력도 없고 제한시간 끝나서 이 글은 끗.





공유하기













[t:/] is not "technology - root". dawnsea, rss